🪟 Windows Qt6 builds

Download Windows Qt6 builds of this PR for testing.
(Built from commit 512447e)

🍎 MacOS Qt6 builds

Download MacOS Qt6 builds of this PR for testing.
This installer is not signed, control+click > open the app to avoid the warning
(Built from commit 512447e)

I don't particularly love the two toolbar approach used here. @nirvn have you any thoughts?

I don't particularly love the two toolbar approach used here. @nirvn have you any thoughts?

The plus and trash icons could also be replaced by actions in the context menu.

It would also help with usability if focus was automatically switched to the newly created toolbar/menu entry.

Is the second search box intentionally disabled? I can imagine it being useful when looking for items to add.

Looking forward to this feature, it's something I've often heard requests for!

I think that from an end-user perspective the UX would be a lot more approachable if the object names (m*) would have less emphasis (at least switching name and label columns, but I think best would to remove the object name column entirely (the object name can still be shown in a tooltip for those who do need it)).

Also, while having D&D is really nice that's sadly a UX that's "invisible" and thus something users might overlook (I just recently had to explain the drag and drop form designer to a user, which even has "drag and drop" in the name...). A common solution is having button(s) between the two lists, like in QgsLayerTreeEmbeddedConfigWidget.

I don't particularly love the two toolbar approach used here. @nirvn have you any thoughts?

Right, I'm gonna migrate the other buttons in the first one

The plus and trash icons could also be replaced by actions in the context menu.

Why not having both ?

I like buttons because it explicitly indicate to the user how he can add/remove a user menu/action. And the button is greyed out if it's not possible to add/remove which is also a valuable information for the user.

It would also help with usability if focus was automatically switched to the newly created toolbar/menu entry.

👍 will do

Is the second search box intentionally disabled? I can imagine it being useful when looking for items to add.

It's an issue, I will fix it

I think that from an end-user perspective the UX would be a lot more approachable if the object names (m*) would have less emphasis (at least switching name and label columns, but I think best would to remove the object name column entirely (the object name can still be shown in a tooltip for those who do need it)).

I thought about removing this column and display only label text (and display name when there is no label text), but I didn't want to change too much the actual display. @uclaros @nyalldawson any opinion on that?

Also, while having D&D is really nice that's sadly a UX that's "invisible" and thus something users might overlook (I just recently had to explain the drag and drop form designer to a user, which even has "drag and drop" in the name...). A common solution is having button(s) between the two lists, like in QgsLayerTreeEmbeddedConfigWidget.

Right. Will do it.

Also, while having D&D is really nice that's sadly a UX that's "invisible" and thus something users might overlook (I just recently had to explain the drag and drop form designer to a user, which even has "drag and drop" in the name...). A common solution is having button(s) between the two lists, like in QgsLayerTreeEmbeddedConfigWidget.

Right. Will do it.

@02JanDal After a second thoughts I don't think button would play nicely here. User would have to:

• Select the action(s) he wants to add,
• The menu/toolbar he wants to add them into,
• And finally click the button.

It seems a little bit convoluted to me. We can maybe print a message in the status bar when user choose to open the action panel to indicate that user can drag'n drop the actions in menu/toolbar.

It seems a little bit convoluted to me. We can maybe print a message in the status bar when user choose to open the action panel to indicate that user can drag'n drop the actions in menu/toolbar.

Hm, that's indeed true, having multiple "targets" does make that pattern maybe even more confusing...

Maybe just a simple label with some basic instructions could work?

The plus and trash icons could also be replaced by actions in the context menu.

Why not having both ?

To avoid the double toolbar that Nyall mentioned above. I'm not against the buttons, it's just that their location is weird. Maybe if the three new buttons were moved to the master toolbar it would be better.

I think that from an end-user perspective the UX would be a lot more approachable if the object names (m*) would have less emphasis (at least switching name and label columns, but I think best would to remove the object name column entirely (the object name can still be shown in a tooltip for those who do need it)).

I thought about removing this column and display only label text (and display name when there is no label text), but I didn't want to change too much the actual display. @uclaros @nyalldawson any opinion on that?

Since there are both entries without a name and entries without a label, we probably should keep both! Maybe the label could be placed first as it makes more sense to most users.

Maybe if the three new buttons were moved to the master toolbar it would be better.

Done

Maybe just a simple label with some basic instructions could work?

for now, I just added tooltips on action panel visibility button and on action tree view. I'm not sure about adding an extra label somewhere, I'm afraid it look a bit odd/clumsy.

Since there are both entries without a name and entries without a label, we probably should keep both! Maybe the label could be placed first as it makes more sense to most users.

I failed to find entries without name (and that could be overcome easily by just settings a name) while there are some entries without label. IMHO it would be weird to have a first column empty.

Any other UI comment have been taken care and I updated the screencast

I failed to find entries without name (and that could be overcome easily by just settings a name) while there are some entries without label. IMHO it would be weird to have a first column empty.

@uclaros Thank you for pointing this out. Action with no name cannot be referenced in user defined menu or toolbar. I'm planning to add a CI test that check that any application action has an objectName to solve the issue. What do you think?

Why static here ? Is it for symbol hiding ? If so maybe I can use anonymous namespace instead ?*

Just a GDAL reflex since that would trigger a warning with -Wmissing-declarations but that might not be enabled for QGIS. Yes, an anonymous namespace would also do the job

Just added a tooltip to explicit drag'n drop behavior. All comments have been processed. Is it ok for you @rouault ?

@troopa81

This pull request has been tagged for the changelog.

• The description will be harvested so please provide a "nearly-ready" text for the final changelog
• If possible, add a nice illustration of the feature. Only the first one in the description will be harvested (GIF accepted as well)
• If you can, it's better to give credits to your sponsor, see below for different formats.

You can edit the description.

Thank you!

@troopa81
A documentation ticket has been opened at qgis/QGIS-Documentation#10685
It is your responsibility to visit this ticket and add as much detail as possible for the documentation team to correctly document this change.
Thank you!